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See you next time.
So, first we're going to talk about the point of this whole idea.
Why test systems in the first place?
We're going to talk about when you're an organization looking to implement a VPN,
what are you facing?
What do you got to think about?
What do you have to worry about?
We're going to talk about when you're writing a VPN,
if you want to architect one of these things,
what do you have to keep in mind?
What are the minimum things that a VPN must do in order to actually be functional as one?
And finally, we're going to look at the theoretical VPN,
which is...
in rough shape.
Okay.
Why go after VPNs?
I mean, you know,
why not hack something else, you know?
I'm just going to pretend that we're all good guys here for a minute
and just tell you, straightforward,
what it is that I see happening
as kind of a historical perspective
and what's happening right now.
Once upon a time,
you know, firewalls were new.
And they were the thing that businesses would do to secure themselves.
You know, you'd hear it.
And it's like, oh, we've got a firewall.
We're fine.
We don't have to worry about anything.
You know, we're safe now.
And it didn't, you know, it's not like we've got this kind of firewall.
You know, and like nowadays, you'll hear people say,
oh, yeah, we're running checkpoint 4.1.
We're current on the patches.
We've got a Nokia 650.
We've got, we're using VRRP to balance them.
We've got failover.
You know, they're detailed about it.
And the reason...
And the reason why is because now they know
that there's a difference between one firewall and another.
It used to be it wasn't that way.
It was like, we've got a firewall.
That's fine.
Because they didn't know the difference.
They didn't know the difference, that is,
until people started taking firewalls
and poking around them
and trying to find ways to break them,
find ways to get around them,
ways to make them fail,
find what's wrong with them.
Once they did, they told the public.
Once they told the public,
the public knew.
And at one point, everything changed
and people started paying attention
when they bought firewalls.
Well, now, it seems to be that way with VPNs for the most part.
People look at the box,
they listen to the sales pitch,
they hear a tripled S.
Okay, it's fine.
It's not.
VPNs can be good.
VPNs can be bad.
People don't know how to tell the difference yet.
And so it's like the emperor's new tailor.
You know, okay, maybe it's a good VPN.
Maybe it's...
Oh, sorry.
Thank you.
I'm running off my notes here on paper.
And I've got this up here.
VPNs are the new emperor's haberdasher, so to speak.
You know, maybe the emperor really is nicely clothed.
He's all set.
He's covered.
Everything's beautiful.
He's styling.
Then again, maybe he's just butt-ass naked
and nobody knows yet.
Somebody needs to go down to the parade
and see if they can get a look at his crown jewels.
You know, and that's somebody.
That's somebody is us.
Who else is going to do it?
I mean,
the people who make the VPN,
there's no motive to do that.
And this is a well-known...
The capitalist system, I've heard,
is the worst one in the world
except for all the other ones.
And it's true.
There's drawbacks. We know that.
And one of those drawbacks is that businesses
tend not to police themselves.
There are good ones. They do the right thing.
They're altruistic.
But for the most part, we know. We're not stupid.
Don't count on industries to police themselves.
You don't have to have somebody
looking over their shoulder
making sure they're doing the right thing.
That's why we have some degree of regulation.
That's why we have watchdog groups.
That's why we have DEF CON.
Thank you.
You know, the client, typically,
you know, all the clients out there,
you can't expect all of them to know
how to assess a VPN in a really deep way.
You know, they just don't have that expertise.
That's why security consultants are still
doing pretty well, even with the tech slowdown.
You know, there's demand out there for the expertise.
It's kind of scarce.
So definitely the clients don't have it.
So the best bet is somebody who doesn't have
any kind of a vested interest.
And again, that's us.
We're not getting paid by one.
We're not getting employed by the other.
You know, we take a VPN.
We look at it.
If we find a hole, we get bragging rights.
But we can't make it look like there's a hole
if there isn't.
And it's as simple as that.
Okay.
Basics of VPNs.
They can encrypt all traffic
or just specific kinds of traffic.
That has to do with the rule base.
We'll go into that later.
They can encrypt between two computers, two points,
or between entire networks,
enabling you to kind of extend your LAN
to a certain degree out to a remote location.
They can be hardware-based,
like the Red Creek products,
or Cisco.
They can be software-based,
like Check Point, or, you know,
any number of other options.
And they'll use various levels
and types of encryption,
based upon whether or not they're intended
to be exportable.
And that's a very critical point
that we'll stumble upon later.
Oh.
One thing.
I just want to throw this out there.
I'm really disappointed that XOR
didn't get chosen for the new AES standard.
You know.
Double XOR.
Hey, triple XOR.
What do you think?
XOR's mad fast.
Yeah, XOR is mad fast.
Mad fast.
Okay.
As you all know,
export restrictions are based upon key size.
One thing a lot of you don't know
is although the restrictions have been lightened up,
they haven't been lightened
in exactly the right way.
You can export tripled S,
provided
you do key escrow.
That's a little bit of a problem.
Key escrow is a slight nightmare.
And we'll talk about that why.
Okay.
So you are a company. Why?
What do you get from using a VPN?
One, if you've got multiple offices,
you can share
network level resources securely
between them without a lot of trouble.
You don't have to have dedicated lines.
Oh.
You don't have to have
really expensive dedicated lines.
You don't have to mess around with it.
You don't have to worry about security.
You can have your exchange server back at the home office.
Have your desktop user in another state.
Pull up Outlook.
Authenticate to the exchange server.
Pull up their mail.
It's all transparent. They don't have to bother.
It's easy. It's simple. It's cool.
If you've got remote users,
big sales force in the field.
Used to be you had dial up through 800 numbers.
Incredibly expensive.
And not exactly secure.
I'm sure...
Does anyone here have a word out?
No?
Then this is all wrong.
We should go back to dial up.
Okay.
But yeah, instead they can just dial up locally
into an ISP.
The ISP takes care of the headaches of rebooting the modems
when they lock up, doing all that stuff.
They'll use a VPN client like Secure Remote.
They'll tunnel through.
They'll have access to the network resources.
And they're good. And it's cheap.
Also,
take that one step farther,
telecommuters with broadband.
They can make almost as much use
of the network resources as the remote office.
Again, you're going to use some kind of a client.
Like Secure Remote, Secure Client.
There's a bunch of them.
I've been doing a lot of Checkpoint lately,
so forgive me if I just lean hard
on the Checkpoint stuff.
It's just what pops to my mind at the moment.
...
Okay.
Challenges for a VPN.
Speed.
It's a network device.
It's transparent.
So it's got to be as fast as possible.
But that's hard to do
because it's got this overhead to crypt everything.
It's hard enough to keep your uptime going
with all the hops
and the internet's
getting a little crazy lately.
So speed's hard enough
without having to process all the packets
and change them.
And then unchange them again
at the other end.
You've got to worry about uptime.
Your connection has to stay up.
If a normal network connection breaks
for just a few seconds,
it comes back up
when it comes back up.
The router reboots,
or whatever
failover system picks up.
Everything goes back to normal
just like that.
No big deal.
With a VPN,
well, the connection goes down,
your VPN goes down,
your VPN might not come back up.
Or for that matter,
stuff that won't put a router down
like some straightforward little glitch in software,
that'll put a VPN connection down.
Some VPNs are very flaky.
They tend to go down all the time
and that's a major problem.
Sometimes you have to worry about
the reestablishment.
Session key is all over again.
These connections pile up,
they're pending, they're trying to recover,
they're trying to reestablish,
and things get a little messy.
Scalability.
That's a big thing.
It's hard to guess
what your traffic's going to look like
using a VPN if you've never used one before.
It could be you think,
it's going to be really simple.
They're just going to check mail.
You've never done this before.
You've never put Microsoft Exchange over a VPN.
You don't know what kind of traffic
they're going to get.
You don't know exactly whether
they're going to be checking their schedule.
You don't know what it's going to be like
when they download that 2 meg file across a VPN.
You don't know whether this user over there
is using local folders
and so as soon as he plugs in,
it belches all the email to his laptop.
It's a tough call.
It's hard to predict how big
you're going to get
and what traffic you're going to get.
It's always the case that
people always plan for less users
than they actually end up having
and that's another issue too.
Interoperability can be a problem.
I think people have pretty much given up
expecting that this VPN
should be able to talk to that VPN.
It just isn't working out that way.
Down the road,
IPsec will probably take care of that
but everyone's just content to wait
until that day comes.
But you have interoperability problems
within a single VPN system
if you have to have mixed levels of crypto.
And you're not a financial services company,
you might not be able to export
strong cryptography
without using Kiesco
which means that your field office in France
is running 40-bit.
Your field office in San Francisco
is running triple-desk 156.
Your VPN's got to be able to talk to both of them.
It's got to be flexible.
Okay.
Risks involved in VPNs.
You know, nothing's perfect.
You always have some kind of a trade-off.
There's always some thorn on the rose.
First of all, since VPNs work across
public networks and they're supposed to,
they must be publicly addressable.
If you've got a gateway that's only supposed to
talk to another gateway
and you know that this IP
will always talk to that IP
and vice versa, and never any other one,
okay, you can hide them in the firewall rules.
That's no problem.
But that's not all that common.
Most of the time, what you're going to have
is a VPN that is visible to everybody.
Including whatever script kitty
might be in the third row right now.
Sorry to the third row, I just had to pick a number.
You have to worry about where you put a VPN
on your network.
The trick is,
if you put it on your firewall,
we'll put it on the DMZ
because it accepts connections from the outside world.
Sensitive, unencrypted traffic
goes into the DMZ from your back network,
goes to the VPN,
comes from the VPN, back out,
goes out to the internet.
Encrypted traffic comes in from the internet,
goes to the VPN to the DMZ,
comes out of the VPN,
unencrypted, in the DMZ still,
goes back to your back network.
And then somebody
hacks your web server
and puts a sniffer on it.
This is bad.
Put it in front of the firewall.
Oh, that's good.
Hey, let's install it
on NT, too.
Service pack 3?
That's a lot of trouble, man.
I never bothered with service packs.
There you go.
Okay, so you can't put it
in front of your firewall
and you got some trouble if you put it in your DMZ.
Definitely do not want to put it
on your back network because that's just like
a rule of thumb.
Don't accept connections from the outside,
untrusted world into your back network.
That's very, very risky.
And the reason why is because you don't know
what vulnerabilities might come up later.
If the public cannot directly address a box,
the public cannot directly attack it.
They'll have to hopscotch through another point.
And that buys you enough time that you might
just notice them coming.
Or not.
You can put it on the firewall.
You know, going back to Check Point,
that's an option.
Thing is, though, the firewall's already pretty busy.
And you put encryption on it,
man, that's a lot of memory,
that's a lot of processor overhead,
and it goes back to what I was talking about
before about you just don't know
exactly how heavily hit this thing's gonna be
once you start using it.
So you might end up taking your network connection down
or really, really, really downgrading
your performance across the board
for both VPN traffic
and regular traffic.
And that's a problem.
That's gonna get you fired.
Okay, how to bake a VPN.
Thinking about this,
I was thinking more in kind of a
Betty Crocker concept,
but I see it up there
and I was thinking, well, no,
I'm not at the part where you learn
how to attack one yet.
You got three things that a VPN must have.
One of them is crypto.
Duh.
One of them is authentication controls.
The other one are rules defining what will
and won't be sent over the connection,
the encrypted connection,
and in what way.
Ingredient one, the crypto.
Okay.
Here's the challenge.
You've gotta encrypt communications
and everything else in the VPN
revolves around this function.
This is the core, this is the reason for being.
What do you use for crypto?
You got two categories,
two general categories of crypto.
You have public key and you got symmetric.
Well, you can't use public key
for all your traffic
because it just takes forever.
That goes back to the speed issue.
Very processor intensive.
And if I remember correctly, some of them actually
take forever.
Yeah.
By a lot.
Which is, you know, not what you want
over your internet link.
Okay, so you gotta use symmetric.
Well, okay.
Shared secret.
How do you share the secret
so that you can establish trusted communications?
It's a catch 22.
You can't trust your communications channels
so you set up a VPN
but you can't set up the VPN
because you can't trust your communications channels.
Well, Diffie-Hellman is what gets us there.
I'm just gonna
blow through Diffie-Hellman real quick, just in case,
just to cover it.
Diffie-Hellman in a nutshell.
It's RFC 2631.
We're gonna talk about it in a kind of Dick and Jane
concept that'll follow through
for the rest of the presentation.
You got Dick and Jane, they need to derive a shared secret.
They don't want to pass anything across the network
that a bad guy could see
and use against them.
So, Dick and Jane create a key pair.
A public and a private key each.
Dick sends his public key to Jane.
Jane sends her a public key to Dick.
Dick encrypts Jane's public key with his private key
and vice versa for Jane.
Both encryption actions
result in the same thing.
They now have a shared secret.
But the nice thing is they've never had to send their private key
which is the thing that they have to protect
over the wire.
So therefore, nobody knows what the private key is
for either party
and nobody can derive the shared secret
except Dick and Jane.
Diffie-Hellman requires random
numbers for key pair generation
so that nobody can guess
because there's basically two variables
there's a large prime number
of which there are a finite number
and then you get a random number
and if you know those two
you can recreate the same thing every single time.
That's the potential weakness of a Diffie-Hellman
is if there's bad random seed.
As you'll notice I say, remember this point.
It will come up later.
And if you really want to look at the math
Okay.
There it is.
I kind of edited it slightly to make it a little clearer
and shoehorned it onto this.
I tried to make it as short as possible
this is about as good as I got it
but you can see here you've got
Jane's public key
Dick's private key
mod p
is the same thing as Dick's public key
encrypted with Jane's private key
mod p
and p is a large prime number
the public key
equals
never mind
it's in the RFC
You know in math
I hate math
I think it was with my girlfriend
when they covered that in college
I had to go back and learn it all over again
it was terrible
Okay, so back to the ingredients.
Does your VPN protect Dick?
Okay, so now you've got the ability to do symmetric cryptography
you've got the Diffie-Hellman
it's going cool
What symmetric algorithm do you want to use?
Most people are using triple desk
that's the buzzword that the marketing people are throwing around
that's what everyone wants to buy right now
You've got other stuff like elliptical curve
that seems to be pretty good too
I heard some stuff on Real Secure
I hear it just a little bit before this
That uses elliptical typically
although you can use whatever crypto provider you want
there's a few of them
elliptical is the choice
Like I said before
strong crypto requires key escrow
or else they're not going to let you send it to the other worlds
because God knows what would happen
if Hussein ever got his hands
on a copy
of the 128-bit version
of Internet Explorer 5.5
Oh my God
I stay awake at night thinking about that
We will be assuming that the implementation
we discuss here is using triple desk
because, well, it is
We'll also assume that the triple desk
is properly implemented
because we have not been able to do code review
to ensure that it is
but all indications are that it's pretty good
I should note here, however, that
triple desk, like any other algorithm
is dependent upon certain variables
